1. Technical Field
The invention relates to accounts that support financial transactions over a computer network. More particularly, the invention relates to a combining multiple financial transactions, where such transactions are of an amount that is below a minimum acceptable threshold for consummating a standard transaction with an acquirer.
2. Description of the Prior Art
A fast-growing trend on the Internet is the ordering and provision of information, goods and services via the World Wide Web, electronic mail, and other means. A key issue for this electronic commerce is how payments may be accomplished efficiently, reliably, and securely. A number of organizations have addressed this issue by establishing proprietary payment systems which vary widely in design, performance, and security features. This clearly calls for standardization.
Payments in the non-electronic world are accomplished via cash, checks, credit and debit cards, money, postal orders, and other mechanisms. Electronic equivalents of all these payment systems are being developed. See, for example M. Linehan, G. Tsudik, Internet Keyed Payments Protocol (iKP), Internet-Draft &lt;draft-tsudik-ikp-00.txt&gt; (July 1995) (an architecture for secure payments that involves three or more participants in which a base protocol includes a number of options that can be selected to meet varying business or security requirements, for example by applying cryptographic techniques to minimize potential risks concerning payments over the open Internet).
See, also L. Stein, E. Stefferud, N. Borenstein, M. Rose, The Green Commerce Model, First Virtual Holdings, Inc., October 1994 (http:.backslash..backslash.www.infohaus.com); N. Borenstein, M. Rose, The application/green-commerce MIME Content-type, First Virtual Holdings, Inc., October 1994 (http:.backslash..backslash.www.infohaus.com); and Encryption and Internet Commerce, First Virtual Holdings, Inc., 1995 (http:.backslash..backslash.www.infohaus.com); and First Virtual Holdings, Inc., Wired, pp. 51 (October 1995), MacWorld, pp. 114 (November 1995) (an on-line transaction clearing house in which accounts are established off-line via telephone, and in which a transaction requires an account number, where each transaction is confirmed by the clearing house via email); CyberCash, MacWorld, pp. 114 (November 1995) (an electronic payment system that uses cryptography to prevent eavesdroppers from stealing and unscrupulous merchants from overcharging); NetCheque, University of Southern California, MacWorld, pp. 114 (November 1995) (an on-line checking system in which an account holder can send an electronic document that a recipient can deposit electronically into a bank account as a check, where the document contains the name of the payer, financial institution, payer's account number, payee's name, and amount of check, and which includes a digital signature of the payer and which may include a digital signature of a payee); and DigiCash, MacWorld, pp. 114 (November 1995) (an Internet payment systems, referred to as eCash, that provides digital money without an audit trail, thereby protecting the privacy of parties to the transaction).
Additionally, electronic commerce systems have been proposed by Visa International Service Association in collaboration with Microsoft Corporation (Secure Transaction Technology, using digital signature to authenticate a credit card and merchant decal; see http:.backslash..backslash.www.visa.com); and MasterCard (Secure Electronic Payment Protocol, a collection of elements including an authorized holder of a bankcard supported by an issuer and registered to perform electronic commerce, a merchant of goods, services, and/or information who accepts payment from the holder electronically, a MasterCard member financial institution that supports merchants by providing service for processing credit card based transactions, a certificate management system that provides for the creation and distribution of electronic certificates for merchants, financial institutions, and cardholders, and a network to interface the merchants, financial institutions, cardholders, and certificate management system; see http:.backslash..backslash.www.mastercard.com).
The prior art that is cited above addresses those transactions that normally exceed a certain monetary threshold, such as the minimum sales amount that a merchant would normally allow a customer to charge on a credit card.
One system that is intended to support such micromerchants is described in NetBill: An Internet Commerce system Optimized for Network Delivered Services, Carnegie Mellon University, http:.backslash..backslash.www.ini.cmu.edu:80.backslash.netbill (1995), which uses a single protocol that supports charging in a wide range of service interactions. For example, NetBill provides transaction support through libraries integrated with different client-server pairs. These libraries use a single transaction-oriented protocol for communication between client and server and NetBill; the normal communications model between client and server is unchanged.
In NetBill, the client library and the server library incorporate all security and payment protocols, relieving the client/server application developer from having to worry about these issues. All network communications between the checkbook and till are encrypted to protect against adversaries who eavesdrop or inject messages.
Before a customer begins a typical NetBill transaction, he usually contacts a server to locate information or a service of interest. The transaction begins when the customer requests a formal price quote for a product. The customer's client application then indicates to the checkbook library that it would like a price quote from a particular merchant for a specified product. The checkbook library sends an authenticated request for a quote to the till library which forwards it to the merchant's application. The merchant then must invoke an algorithm to determine a price for the authenticated user. He returns the digitally signed price quote through the till, to the checkbook, and on to the customer's application. The customer's application then must make a purchase decision.
The application can present the price quote to the customer or it can approve the purchase without prompting the customer.
If the customer's application accepts the price quote. The checkbook then sends a digitally signed purchase request to the merchant's till. The till then requests the information goods from the merchant's application and sends them to the customer's checkbook encrypted in a one-time key, and computes a cryptographic checksum on the encrypted message. As the checkbook receives the bits, it writes them to stable storage. When the transfer is complete, the checkbook computes its own cryptographic checksum on the encrypted goods and returns to the till a digitally signed message specifying the product identifier, the accepted price, the cryptographic checksum, and a timeout stamp.
Upon receipt of the electronic payment order, the till checks its checksum against the one computed by the checkbook. If they do not match, then the goods can either be retransmitted, or the transaction aborted at this point. If checksums match, the merchant's application creates a digitally signed invoice consisting of price quote, checksum, and the decryption key for the goods. The application sends both the electronic payment order and the invoice to the NetBill server. The NetBill server verifies that the product identifiers, prices and checksums are all in agreement.
If the customer has the necessary funds or credit in his account, the NetBill server debits the customer's account and credits the merchant's account, logs the transaction, and saves a copy of the decryption key. The NetBill server then returns to the merchant a digitally signed message containing an approval, or an error code indicating why the transaction failed. The merchant's application forwards the NetBill server's reply and (if appropriate) the decryption key to the checkbook.
Unfortunately, however useful support for such micromerchants may be, the NetBill system requires excessive network bandwidth to support the multiple data transfers between the NetBill server.
iKP, ibid., et al address a subset of the real world mechanisms that involve direct payment transfers among accounts maintained by banks and other financial organizations. This includes credit and debit card transactions, as well as electronic check clearing, but excludes electronic cash and money orders because these transaction require very different mechanisms. The goal of iKP is to enable Internet-based secure electronic payments while using the existing financial infrastructure for payment authorization and clearance. The intent is to avoid completely, or at least minimize, changes to the existing financial infrastructure outside the Internet.
Payment systems incorporate tradeoffs among cost, timeliness, efficiency, reliability, risk management, and convenience. For example, some systems attempt to suppress fraud by inducing payment delays. Security in payment systems means minimizing risk to a level acceptable to participants. Risk management in existing systems is accomplished by varying combinations of technology, payment practices, insurance, education, laws, contracts, and enforcement. iKP uses cryptographic technology to accomplish a new tradeoff among these competing considerations. Thus, public-key cryptography is adopted to support, in a scalable manner, payments among parties who have no pre-existing relationship. To facilitate export of iKP, the use of encryption is restricted to the protection of sensitive data, such as PINs and account numbers. To provide broad implementation flexibility, the iKP protocol is defined such that it can be implemented in any combination of software and hardware.
Many existing cryptographic protocols, such as SSL (K. E. B. Hickman, The SSL Protocol, Internet Draft &lt;draft-hickman-netscape-ssl-00.txt&gt;, April 1995), SHTTP (E. Rescorla, A. Schiffman, The Secure HyperText Transfer Protocol, Internet Draft &lt;draft-rescorla-shttp-0.txt&gt;, December 1994), PEM (J. Linn, Privacy Enhancement for Internet Electronic Mail: Part I: Message Encryption and Authentication Procedures, RFC 1421, February 1993), MOSS (S. Crocker, N. Freed, J. Galvin, MIME Object Security Services, Internet Draft &lt;draft-ietf-pem-mime-08.txt&gt;, March 1995), and IPSP (R. Atkinson, Security Architecture for the Internet Protocol, Internet Draft &lt;draft-ietf-ipsec-arch-02.txt&gt;, May 1995), provide security functions for pairwise communication.
For example, SSL provides privacy and authentication, but no non-repudiation, between clients and servers of application-layer protocols, such as HTTP and FTP. Many payment systems involve three or more parties, i.e. buyer, seller, and bank. In such systems, certain types of risk can be amellorated by sharing sensitive information only among a subset of the parties. For example, credit card fraud can be reduced by transmitting credit card account numbers between buyers and banks without revealing them to sellers. This motivates the development of new protocols.
Both symmetric key and public key cryptographic systems are known. A symmetric key cryptographic system is so called because it uses the same key to encode the message as to decode it. Examples of such system run from simple substitution ciphers that have been known for 2000 years, to the cipher system invented by Thomas Jefferson that was actually used by the U.S. in World War II, and the recently adopted the Data Encryption Standard. The advantage of such systems is that they are generally fast given modern day computers and they are reasonably secure.
A big disadvantage of such systems is that two communicating parties must have arranged to share the key in advance. However, one cannot always know in advance with whom one might want to communicate in a secure fashion. Thus, such a system is inadequate for network communication where people want to communicate securely with each other on very short notice, but have not arranged ahead of time to share a key. Even if there was adequate time, the cost of sharing a key would not necessarily be inexpensive because the system would still require a secure form of mail to transmit the key ahead of time.
The invention of the public key system solved this problem. The public key system provides two keys for a message, a public key and a private key. The public key is known to all who want to know it, while the private key is only known to the person who whose security is at stake. The public key is used to encode the message and the private key is used to decode the message. Thus, if A wants to send a message to B, A first encodes the message using B's public key and then sends the message to B. B decodes the message using his private key. If B wanted to send a message to A in response, he would similarly use A's public key to encode the response, and A would decode such response using A's private key.
The best known public key system, RSA, is based on a private key consisting of two large prime factors and a public key which is the composite that is the product of the two primes. What makes this RSA work is that the decoding problem is equivalent to factoring the composite into its primes which is a very time-consuming calculation, compared to multiplying the prime numbers together to get the composite.
One disadvantage of the public key system is that it takes more computation to perform the encoding step than do symmetrical key systems. While the computation time is acceptable for many purposes, it is significantly slower than symmetric key systems, such as DES. This becomes a problem when one considers the sending of voluminous amounts of encrypted material.
The prior art also includes systems which combine both systems. Thus, if party A and party B wish to communicate, party A selects a symmetrical (e.g. DES) key, encodes it using B's public key, and sends it to B. B decodes it using his private key. Now that both have a copy of the same symmetrical key, they can securely communicate using that key.
Another important aspect of the public key system is the digital signature. A digital signature is a message that is encoded by A in A's private key that can be read by anyone using A's public key. This is called a digital signature because only A is assumed to have the private key, so any message encoded in it must have been sent by, or at least authorized by A. It should be noted that a message bearing A's digital signature can be encrypted in B's public key and sent to B. This message is now one that only B (or a possessor of B's private key) can read, and it is also ensured to be an authentic message from A as it was encoded uses A's private key.